In recent years there has been a great proliferation in small computer hardware and in the various functions capable of being performed by such computer systems. While the systems were earlier used primarily for accounting and data base management tasks, highly sophisticated programs for word processing and graphics composition have enabled the so-called personal computers to become even more popular.
For the traditional accounting and data base management tasks, it is necessary to display and print only a rather limited set of alphanumeric characters and symbols. Since the number of different characters and symbols to be displayed and printed is relatively low, it is also unnecessary to generate from the keyboard or other character input device, and handle within the program, any more than this relatively low number of characters and symbols. However, with word processing and graphics applications, the requirement for much larger sets of alphanumeric and graphic symbols has arisen.
Personal computers use ASCII (American Standard Code for Information Interchange) data transmission code to convey alphanumeric character and symbol information between the various devices of the computer system. For example, the IBM Personal Computer operates in this ASCII environment whereby data sent to the display, print, or magnetic storage device is conveyed with the standardized ASCII coding. However, the ASCII code set is presently limited to a character set of 256 alphanumeric characters and symbols. While this ASCII based code set is a workable expedient for handling the majority of characters and symbols desired to be used on most small computers, it is by no means capable of supporting all of the characters and symbols in all of the languages for which a popular series of computers is sold.
The International Business Machines Corporation uses a Multilingual Graphics code translation technique which is based on an eight bit EBCDIC (Expanded Binary Coded Decimal Interchange Code) code point and a sixteen bit Code Page Identifier. Thus, each code input to the system (in ASCII or other format) is converted to an eight bit EBCDIC code point along with a sixteen bit identifier of the Code Page to which the eight bit EBCDIC Code Page refers. Therefore, if ASCII is the code input to this technique, it will be understood that an eight bit ASCII code is expanded by this MLG technique into twenty-four bits of information. This means, of course, that many more symbols of many more languages can be handled when twenty-four bits are available for their identification rather than eight bits. With the exception of the IBM Personal Computer family, the IBM Corporation uses the MLG technique with most of the other computer products that it markets. For word processing application programs designed to run on the IBM Personal Computer family, most developers of such software other than IBM have remained within the ASCII code environment. In contrast, IBM's DisplayWrite 2 and 3 programs use the MLG EBCDIC technique of handling text and symbols. As a result of this, these programs are not limited to the 256 text and symbol characters available in ASCII, but, instead are capable of handling many accented characters and other symbols beyond those normally handled in English documents.
With this approach, however, a very significant problem exists in that the IBM Personal Computers sold in one country may differ in their handling of certain coded characters from the way other IBM Personal Computers handle those same keyed characters. For programs such as the aforementioned IBM DisplayWrite 2 and DisplayWrite 3 applications, it was then necessary to modify the programs to run correctly on the slightly different hardware. That is, it was necessary to modify the program to convert a particular ASCII code point generated from the keyboard into the corresponding character in MLG that that particular country intended to be described by that particular ASCII code point. Thus, it will be understood that the software industry is now having to deal with machines in which the ASCII definition of the character or symbol to be represented by a particular code point may vary depending on the country.
It will therefore be understood that a basic problem exists in ensuring that a text processing program operates as intended when it is capable of being loaded into a variety of identical looking machines which may handle the ASCII code points in varying ways. The previous method used by IBM for the DisplayWrite 2 program to support all of the various countries, required modifications to the program and extensive testing to make sure that the programs were correctly modified to properly operate on the different hardware. This problem is further compounded when marketing of the hardware and software are considered in additional countries with additional, unusual language requirements. However, without modification to the programs, it is easy to understand how many characters and/or symbols will be reproduced in a manner other than that intended if the program is not fully compatible with the hardware.
A somewhat similar problem with compatibility has been addressed relative to printers which were, perhaps, one of the first devices to exhibit a deviation from the ASCII "standard." Most printers do not define all of the ASCII code points. In addition to not supporting the complete ASCII set, many printers also require a different mapping than that defined by the IBM Personal Computer. This different mapping is especially noticeable in printers that were in existence prior to the release of the IBM Personal Computer. Applications which need to work with these printers must include some method for describing the special character mappings. Most early applications included this information within the program. The disadvantages of this became apparent with the dramatic increase in the number of printers available. It is no longer reasonable to change the application program every time support for a new printer is desired. A solution to this problem with printers was to utilize predefined external tables for conversion of particular codes in the program to the desired printer codes. This prevented having to change the application program to support each additional printer The ultimate solution to this problem is described in copending U.S. Pat. No. 4,710,886, filed Oct. 24, 1984, issued Dec. 1,1987 in which the user is given the capability to create his own external table to define the particular mapping of his printer. The above described solution to the printer compatibility problem, however, is effective only when the IBM DisplayWrite 3 word processing program and hardware are "synchronized." Such synchronization only occurs when the ASCII to MLG and MLG to ASCII translations within the DisplayWrite program are compatible with the intended meanings of the ASCII code points at the hardware level. Thus, the solution of a user defined printer table does not address the potential hardware/software compatibility problem.
Therefore, it would be greatly advantageous if a technique were made available to provide compatibility between a generic program and varying hardware configurations on which it might be operated to assure that particular ASCII code points are handled by the system as intended by the operator.